\subsection{Diagramas de Actividades}

En esta sección vamos a explicar los diagramas de actividad que consideramos relevantes y que corresponden al análisis del software a construir. Con estos diagramas modelaremos las situaciones donde se realiza un circuito de despacho de pedido, uno de stock, y uno de coordinación de menús. Elegimos diagramas de actividad para el modelado de estas situaciones porque este método nos provee claridad para mostrar las actividades que ocurren y a los actores responsables de las mismas. Cada actividad es consecuencia de alguna anterior, el flujo intenta mostrar con claridad una posible secuencia de sucesos que se llevan a cabo para lograr el cometido que modela el diagrama.\\
A continuación mostraremos los diagramas y daremos las explicaciones pertinentes para cada caso.

\subsubsection{Diagrama de actividad: Circuito de Despacho de pedido}

Tomando como referencia el escenario de Ariel pidiendo una grande de muzza, ya tenemos en cuenta que el cliente realiza un pedido. Luego, existe un encargado que toma su pedido y lo ingresa en el software. Este último evalua si es posible realizar el pedido en el local donde fue realizado o en otro. \\
Lo importante de ver es qué requerimientos son cubiertos por este diagrama. Para poder avisarle al cliente en qué local pueden encontrar una variedad de pizza primero necesitamos averiguar qué local dispone el stock necesario para hacerlo, luego debemos poder reservar dicho stock y avisarle al cliente en qué local se realiza ese pedido, para que pueda ir a buscarlo.\\
En este diagrama vemos que el software reserva el stock (siempre y cuando el pedido pueda realizarse) cuando la orden es confirmada, además, notifica al cocinero y luego notifica al mozo que el pedido está finalizado. Esto cumple con los requerimientos en el diagrama de objetivos ``brindar servicio del menú actual a los clientes''.\\
Además, cuando el cocinero informa la finalización del pedido, el software decrementa el stock y chequea si existe algún ingrediente en falta. Si lo hay, envía un aviso de pedido de compra.\\
Una vez finalizado esto, el pedido es entregado al cliente y este se retira.\\
Un aspecto que vale la pena aclarar es que cuando el local sugiere alternativas, realiza un chequeo previo del stock de los locales que sugiere.

\begin{figure}[!ht]
  \begin{center}
	\includegraphics[scale=0.40]{imagenes/diagramas/DiagramaActividad_DespachoPedidos.png}
  \end{center}
  \caption{Diagrama de actividad que representa el despacho de un pedido}
\end{figure}

\clearpage

\subsubsection{Diagrama de actividad: Cancelación de pedido}

Puede darse el caso, que un cliente se arrepienta del pedido que realizó. Cuando esto sucede el software debe liberar el stock asignado a tal pedido, esto, siempre y cuando el pedido no esté en proceso de elaboración.\\
En caso de que el pedido se este elaborando el software no repone el stock, sino que lo decrementa, y como se produce una disminución del mismo, se chequea si existe al menos un ingrediente por debajo del mínimo.\\ 
Esto cumple con los requerimientos de liberación de stock cuando el pedido se cancela y nuevamente, cumplimos con el requerimiento de emisión de pedido de compra cuando un ingrdiente es escaso, así como también el monitoreo de los límites de stock.\\
En la actividad ``chequea si se está realizando el pedido", el software analiza un campo del pedido que le indica si el pedido comenzó a prepararse o esta en espera. Esto facilita el hecho de saber si se puede o no restituir el stock reservado.\\
El monitoreo de los ingredientes en falta no es otra cosa que un chequeo del ingrediente que en ese moemento sufrió una disminución de su cantidad. Esto sirve para enviar una orden de compra al repositor y luego para establecer el nuevo nivel bajo relativo.\\
En todos los casos, el envío de señal de orden de compra es hacia la impresora, y esta, una vez recivida la señal, imprime la orden con todos los datos necesarios.

\begin{figure}[!ht]
  \begin{center}
	\includegraphics[scale=0.50]{imagenes/diagramas/DiagramaActividad_CancelacionPedido.png}
  \end{center}
  \caption{Diagrama de actividad que representa la cancelación de un pedido.}
\end{figure}

\clearpage

\subsubsection{Diagrama de actividad: Circuito de stock}

Aquí dejamos en claro las responsabilidades que tiene el repositor, software y proveedor con respecto a la reposición de stock. Cuando el sistema detecta una falta de ingredientes (tomando como referencia la mínima cantidad que cada uno debe tener) envía una señal a la impresora para que imprima el pedido correspondiente.\\
Luego, cuando el repositor lo lee, se pone en contacto con el proveedor para comprar el ingrediente en falta. Una vez obtenido el mismo, el repositor ingresa en el software la cantidad comprada y luego, este último actualiza los valores de stock.\\
Con esto cumplimos los requerimientos de incremento de stock cuando hay reposición, y sobre todo de actualización del nivel bajo relativo, una vez agregada la nueva cantidad comprada.\\

\begin{figure}[!ht]
  \begin{center}
	\includegraphics[scale=0.45]{imagenes/diagramas/DiagramaActividad_CircuitodeStock.png}
  \end{center}
  \caption{Respresentación del flujo de actividades que involucra el circuito de stock.}
\end{figure}

\clearpage

\subsubsection{Diagrama de actividad: Coordinación de menues}

En este caso, se intenta resaltar cómo un menú es actualizado desde un local particualar, esperando su turno. Algo que debemos notar, es que el jefe de chefs ingresa los cambios cuando lo cree conveniente, luego, el sistema almacena esos cambios y los envía cuando es su turno.\\
Con esto cumplimos los requerimientos de instaurar cambios al menú de un local y de envio de avisos a los otros locales.\\
Cuando un chef decide aplicar cambios, estos se guardan para la espera del turno. Una vez que el local lo obtiene, actualiza su menú y envía los cambios a los demas locales.\\
La actividad ``Actualiza menú'' no se refiere a una actualización global, sino a la actualización del menú de dicho local, la actualización global se llevará a cabo una vez el local pueda enviar los cambios, es decir, cuando le toque su turno.\\
Notemos qué pasaría si algún local se niega a actualizar el menú. Si nuestro local se actualiza y luego envía la nueva información al resto y uno se niega, el menú quedaría inconsistente, y no se podría cumplir con uno de los principales de nuestro sistema.\\
En cuanto al requerimiento de actualización de menú proveniente de otro local, esto se realiza automaticamente cuando llega un aviso. El diagrama de actividad intenta mostrar el escenario en que un jefe de chefs realiza (o no) una actualización, sin tener en cuenta que puede llegar un pedido de actualización en cualquier momento.

\begin{figure}[!ht]
  \begin{center}
	\includegraphics[scale=0.45]{imagenes/diagramas/DiagramaActividad_CoordinacionDeMenu.png}
  \end{center}
  \caption{Actividades correpondientes a la forma de actualizar el menú en una sucursal.}
\end{figure}